Avoid dynamic dispatch in back-end IR code - #1071

Splatting a collection of LLVM values or types into a vector literal
dispatches on the run-time types of the elements, compiling a method
for every combination of instruction and type kinds encountered. Build
these vectors with `collect`, `pushfirst!` or by concatenating
concretely typed collections instead. Also assert the types of the
kernel state getter call and of the caller instruction `backtrace`
moves to, which kept every property access in its loop dynamic.

The comprehension collecting the atomics widened its element type at
run time, so it was inferred as an untyped vector and every helper
called on its elements was dispatched dynamically. Collect into a
`Vector{LLVM.Instruction}`, don't specialize the helpers on the kind of
instruction or pointer (which compiled each of them again for every
kind), and give the other vector literals built from IR objects an
element type.

As for PTX, collect the atomics to lower into a typed vector, don't
specialize the helpers on the kind of instruction or pointer, and build
the argument and parameter-type vectors of the AIR atomic intrinsics by
appending to typed literals rather than by splatting into untyped ones.
Give the table of kernel intrinsics that become arguments concrete key
and value types, which made all of `add_input_arguments!` dynamic. When
emitting argument metadata, assert the types of sizes and address
spaces computed from untyped values, so that the `Int32` and
`ConstantInt` calls on them are resolved statically.

Like for PTX and Metal, the untyped comprehension made every call on
the collected instructions dispatch dynamically.

Their callers only know they have an `LLVM.Instruction` or
`LLVM.Value`, so every call dispatched dynamically and compiled the
helper again for each concrete kind of instruction or pointer it met.
With `@nospecialize`, a single method instance serves all of them and
the calls resolve statically.